Conversation
rphmeier
added
A0-pleasereview 🤓
| --identity NAME Specify your node's name. (default: {flag_identity}) | ||
| --light Experimental: run in light client mode. Light clients | ||
| synchronize a bare minimum of data and fetch necessary | ||
| data on-demand from the network. Much lower in storage, |
There was a problem hiding this comment.
spaces should be used here to guarantee output alignment.
| synchronize a bare minimum of data and fetch necessary | ||
| data on-demand from the network. Much lower in storage, | ||
| potentially higher in bandwidth. Has no effect with | ||
| subcommands (default: {flag_light}) |
There was a problem hiding this comment.
Don't forget the full-stop ..
|
is this really 1,522 −388 ? seems a lot for the documented additional functionality... |
|
It's about +450 for the header chain stuff, +150 for the transaction propagation, +700 for the CLI (generalizing RPC APIs among other things), and then about +200 for miscellania to make the UI function a bit better. |
| } | ||
|
|
||
| fn cht_key(number: u64) -> String { | ||
| format!("canonical_{}", number) |
There was a problem hiding this comment.
Key comparison should work faster if you put the number in the front. Might be also a good idea to use a 4-byte big endian representation instead, so that enumeration would produce a sorted list.
There was a problem hiding this comment.
Are the keys compared during regular lookup? Also, is there a minimum length on keys?
There was a problem hiding this comment.
Are the keys compared during regular lookup?
Pretty sure they are. Database basically performs a binary search.
Also, is there a minimum length on keys?
I believe there is no such minimum.
| }; | ||
|
|
||
| self.headers.read().get(&hash).cloned() | ||
| load_from_db(hash) |
There was a problem hiding this comment.
Probably worth caching the best header in memory.
There was a problem hiding this comment.
The DB should do this automatically, right? I plan to add customized caching in the future but I think it's beyond the scope of this PR.
There was a problem hiding this comment.
Happy if this is added later. The closer is the cache to the code that uses it, the better is performance. Introducing multiple levels of caching can bring huge benefits. Higher level cache usually holds less data but is accessed much more frequently. CPU hardware design generally follows this principle and it often applies to the software as well.
arkpar
added
A6-mustntgrumble 💦
rphmeier
added
A0-pleasereview 🤓
|
@arkpar headerchain grumbles addressed |
arkpar
added
A8-looksgood 🦄
5 participants
Summary of changes:
header_chain.rs)execute_lightfunction toparity/run.rs, triggered on--lightflag.Runs RPC servers, but no DApps yet: Make Dapps server light-client friendly #5001
--no-serve-light.Next needed changes:
on_demandCloses #5012